A database is an organized collection of data. Some databases organize the data into hierarchies. For example, one database object may represent a data center. The datacenter may have one or more devices, and each device may have one or more components. In the example above, the datacenter object is the root of the hierarchy, with devices as children, and each device may have one or more component children.
Object instances in a database commonly have 3 lifecycle states. In the active stage the object has the ability to be updated and form new relationships. In the inactive stage the object is not being updated and not used to form new relationships, but the object is kept for historical persistence. For example, when a new version of the object is created, the old version may be needed for maintaining short term historical persistence and/or for operational reporting. In the deleted stage, the object is no longer needed from an application functional perspective and can be deleted physically or archived. The lifecycle state of an object affects the performance and scalability of the database and the maintainability of the data set.
Problems associated with maintaining lifecycle states for database objects include hindering access to active data, slow or off-line purges of deleted objects, and complex hierarchies. For example, while the inactive objects are necessary for persistence and operational reporting, their existence can slow down the data access to active data due to inflated cardinality. Furthermore, deleted data (e.g., table rows with a deleted lifecycle state) needs to be purged or archived periodically from the database for performance reasons. But row deletion is a very slow operation and may render a row-based purge or archive impractical. Furthermore, row-level deletes cause significant blocking in highly transactional systems, slowing down overall database access times, and leading to fragmentation that requires regular off-line database activity (defragmentation) to maintain adequate database performance. Application program requirements often make off-line cleanup undesirable or impermissible, limiting database objects lifecycle maintenance, including purging deleted objects, to on-line procedures.
Reference partitioning in a database is a method of partitioning of a group of tables together based on reference to a field or fields in another related table. In reference partitioning, every child's partitioning is a function of the partitioning of its parent. In lifecycle management, the partitions may represent the lifecycle state of an object, for example an active partition with database objects in the active stage, an inactive partition with database objects in the inactive stage, and a deleted partition with database objects in the deleted stage, with the child following the lifecycle partition of its parent. Putting inactive and deleted objects in a separate partition speeds access to active data, but many databases do not support reference partitioning, so this method of lifecycle management is unavailable to applications using such databases. Additionally, databases that currently support reference partitioning do not support it for ragged hierarchies, e.g. children having more than one parent, or hierarchies with cycles. Such hierarchies are complex hierarchies, as opposed to simple hierarchies that do not include multiple parents or cycles. Because many real-world applications involve complex hierarchies, and because many databases do not support reference partitioning at all, reference partitioning for lifecycle maintenance currently has limited usefulness.